Relational databases are used to define relationships between items of persistent data. For example; FIG. 1a shows a simplistic arrangement of relationships defined within a relational database. Here, an object oriented environment is assumed where first, second, third and fourth objects are used to represent “Customer A”, “Customer B”, “Order 1” and “Order 2”, respectively.
The relational database entries of FIG. 1a can be used, for example, to keep a record of the items purchased for specific customers. Specifically, specific items purchased by Customer A are listed in the “Order 1” object; and, specific items purchased by Customer B are listed in the “Order 2” object. Here, the Customer A object “represents” Customer A and can be assumed to keep various items that identify Customer A (e.g., name, address, phone number, etc.); and, the Customer B object “represents” Customer B and can be assumed to keep various items that identify Customer B (e.g., name, address, phone number, etc.).
Notions of “navigability” come into play in the design of a relational database. Navigability defines the ordered flow in which elements of data within a relational database can be accessed. For example, according to the simplistic relational database entries observed in FIG. 1a, purchased items listed in “Order 1” can be retrieved with the identity of “Customer A” (and purchased items listed in “Order 2” can be retrieved with the identity of “Customer B”)—but—the identity of “Customer A” can not be retrieved from the records of “Order 1” (and the identity of “Customer B” can not be retrieved from the records of “Order 2”).
Unidirectional relationships 101, 102 enforce the above policy in which information can be obtained in a first direction of object access flow but not in a second. In a typical application, the Customer A object would include information that defines the unidirectional relationship 101 to Order 1 but the Order 1 object would not include any such information (i.e., only the Customer A object has information that corresponds to relationship 101); and, the Customer B object would include information that defines the unidirectional relationship 101 to Order 2 but the Order 2 object would not include any such information (i.e., only the Customer B object has information that corresponds to relationship 102).
In terms used by those in the software arts, it can be said that customer objects have “visibility” to the order objects; but, the order objects do not have “visibility” to the customer objects. Restricting visibility in this manner enforces the unidirectional relationship that is to be implemented into the database. Implementing unidirectional relationships within an object oriented persistent data relational database as described just above can be part of the defined software environment.
For example, the current Java Enterprise Java Bean (EJB) 2.0 specification currently implements a unidirectional relationship by instantiating “accessor” methods in an object having visibility to another object in a unidirectional relationship—but not instantiating such accessor methods in the other object that does not have visibility to the object. A first type of accessor method, referred to as a “set” method, is used to create or change a relationship. A second type of accessor method, referred to as a “get” method, give access to another object from the object that executes the accessor method. The EJB 2.0 specification provides as part of its container managed persistence (CMP) for both types of accessor methods and specifies that objects representing items of persistent data are implemented as “entity beans”. CMP is a service by which the persistence management of beans within an EJB container are managed by the container itself.
Implementing a unidirectional relationship where a first object has “visibility” to a second object but the second object does not have “visibility” to the first object can be inefficient, however, when changes are to be made to existing relationships between existing objects. For example, consider if the working environment of the relational database of FIG. 1a is that: 1) there is to be only one customer per order; and, 2) there are high priority customers and low priority customers where high priority customers are given access to items in shortage over low priority customers.
If Customer A is a high priority customer and Customer B is a low priority customer; and if, Order 2 has every item in Order 1 and includes an item in shortage; then, if Customer A suddenly updates his items for purchase to include the item in shortage, Customer A may be satisfied by “taking” Order 2 from Customer B and dropping Order 1. FIG. 1b represents the resulting object relationships.
Implementing the change, however, can be inefficient because of the lack of visibility that Order 2 had to Customer B in the original set of relationships in FIG. 1a. For example, assume the change is implemented by: 1) first searching through all order objects (which could be many more than those observed in FIG. 1a) to find an order that “matches” the needs of Customer A (to which Order 2 will be a “hit”); and then, 2) establishing the new relationship if the customer of an object identified through 1) is lower priority than Customer A.
Because of the lack of visibility that Order 2 has with respect to Customer B, the second step 2) above can only be accomplished by searching through all customer objects (which again can be many more than those observed in FIG. 1a) to find “the object” (Customer B) that is related 102 to Order 2 so as to resolve the customer priority issue. Thus, as searches can be time consuming, the lack of visibility from Order 2 to Customer B causes changes to be inefficiently implemented when an object whose relationship to be changed (in this case Order 2) is identified before its relationship companion (in this case Customer B); and, the first identified object does not have visibility to the companion.